第11章 現場の状況を目に見えるようにする
11.1 これは・・・荒れる
顧客が無理な要望を出されたときには、いままで出てきてドキュメントを提示して誠実に説明をする。
リリースボード
ストーリーボード
バーダウンチャート
上記のツールを駆使して、要望に対応できない旨を説明すうr
11.2 貼りもの作り方
アジャイルな開発をするのであれば、以下のボードを用意する
ストーリーボード
一番リソースを割かないといけない内容がわかる
リリースボード
現場にいるだれでもプロジェクトの状況がわかる
ベロシティとバーンダウンチャート
現状のプロジェクトの状況がわかる
開発完了予定が現実的か
インセプションデッキ
なぜこの仕事をしているのかを常に意識できる
11.3 チームの意思を明確にする
チームの意思を明確に以下のの内容も目に入る場所に貼っておくといい
チームの約束
「チームとしてこうやって作業したい」ということを宣言したもの
どんなチームをめざしているか
チームメンバーにもとめる条件
Ex
午前9時から午後4時までコアタイム
デイリースタンドアップは午前10時丁度に開始
テストを済ませたら完了
ビルドを大事に
誰かに助けを求められたら「はい、よろこんで」と返事しよう
毎週火曜日午前11からデモをする
午前1時から3時まはお客さまが時間を割いてくれる
チームが大事にすること
より感覚的な目標。今までの反省点からチームで気をつけておきたいことを記載しておき
Ex
手を抜かない
「割窓」を放置しない
異論は認める
真実と向き合う
勝手な想定をしないて確認する
疑わしいと思ったらフィードバックを描く
フィードバックを求める
我を張らない
11.4 プロジェクトで使う言葉を共有する
業務で使用する言葉をソフトウェアに反映しないとさまざまな障害がおきる
開発者と顧客と同じ認識がない言葉を使用してしまう
DBなどに使用してしまうと変更しづらくなる
バグが増えて保守コストが高くつく
これをさけるために顧客を言葉使いルールを徹底する。また、ストーリーボードやソフトウェアに反映する。
打ち合わせで出てきたことは書き留めて、どんな意味をもつのかを定義すること
11.5 バグを監視する
本番リリース時にバグにあわないように、イテレーションで10%の時間を使って技術的負債を解消する時間を作る
不具合をみつけた瞬間をその場で潰してしまうこと